Scan-codes vs Key-codes (posila) While migrating from Allegro to SDL, HanziQ and Jiri replaced the keystroke handling from using key-codes to scan-codes. Before you start jumping with joy, you’ll probably wonder: What is that and why should I care? Well, funny you should ask. You probably won’t care, unless you live outside of USA and/or you use a non-US keyboard layout. In short, key-code is a key identifier dependant on the symbol the key will output when pressed, scan-code is a key identifier based on the physical location of a key. So for example players with French keyboard layout (AZERTY) have to jump to the control options after launching the game for the first time, and remap movement from WASD to ZQSD, in order to be able to move their character without hurting their hand. In 0.17, the controls will map to the correct keys by default, regardless of your layout, and stay mapped to those physical keys even if you for some reason change your keyboard layout while the game is running. The disadvantage is, most of the non-US layouts didn’t end up with completely broken controls, so people kept playing with them and got used to them. So they’ll need to get used to the layout the game was originally designed with, or manually configure controls back to what they are used to. But wait, there is a catch... A few weeks ago we have announced new construction tools, which are by default bound to quite universal shortcuts (Ctrl+C for copy, Ctrl+X for cut and Ctrl+Z for undo). Bilka pointed out that the German keyboard has Z swapped with Y (as does the Czech one, but developers often don't use it) and undo incorrectly defaults to Ctrl+Y instead. To fix these kind of shortcuts we determine the appropriate default scan-codes at start-up, so that undo is always Ctrl+Z, regardless of your layout, but the action will stay bound to those keys if you change keyboard layout at runtime, which is hopefully a reasonable compromise. We might do it for other controls too (it feels natural for M to always be the default key to open the map, and T to open the technology screen), but there is another catch. It is completely reasonable for player to walk north, and Ctrl+click some entities. Remember AZERTY keyboard? Player keeps Z pressed down to walk north and presses Ctrl to start control clicking. Well, I tested this and it doesn’t trigger undo, but still stops player from walking. So it is not completely destructive, rather annoying. I am not sure how or if we’ll solve this, perhaps people with these layouts that create these kind of collisions will need resolve them by changing controls options manually.
Factorio at the National Library of Technology Prague (Klonan) If you are in Prague this summer, and wanting to satiate your Factorio cravings, you can stop in to the National Library of Technology Prague, where Factorio is loaded onto 150 computers for all to play. Entry is free for all visitors Monday to Friday 08:00 - 22:00 until the 31st of August. The PC's are running Linux (Fedora), loaded with a custom build of the game HanziQ put together, and you can host LAN servers and play with your friends. On the 23rd of July we will be hosting our own Factorio LAN party at the library starting at 16:00 CEST (Prague time), so you can come along and play with us. It is advised to bring your own set of headphones if you are going to attend.
New Python developer (Klonan) Mobile users may see that the website is significantly easier to read today, that is all thanks to our new Python developer Sanqui. Apart from making our website more mobile friendly, we have a lot of tasks on the backlog that he will start working on soon. His first major task is to speed up and optimize the matching server, with which he is already making some progress. A bigger rewrite for the long term is underway, but in the last week he has reduced a lot of the slowness and timeouts people were seeing during peak times. He will be taking over our database management and web administration from HanziQ, as well as spending time cleaning up our codebase, maintaining our web services, and developing features for the mod portal.
Hello, it has been extremely cold these last weeks. It's one of those weeks when we can't think of anything to write about. So we will try to write some small parts.
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
Hello, another week has passed here, with part of the team still out in Taiwan. They should be back next week, with some news of their great adventure.
Hello, there has been an illness running around the office this week, so productivity has been down. Regardless, it is still friday, so here are the Factorio Facts.
Alpha blending and pre-multiplied alpha From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha. When the GPU is figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'): You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque. In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation: Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha. Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending: This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering. For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke. Textures with pre-multiplied alpha also produce better results in texture filtering , which is probably the main reason why they are so widely used in the videogame industry.
Nightvision nightmare As Twinsen continues tweaking the combat, he started to complain about the “green fog” effect that is applied during night when the player’s character has nightvision goggles equipped. Nightvison in 0.14 works in a way that it reduces the darkness of night, and then draws a transparent green overlay. This washes out the colors, reduces contrast, and makes the picture pretty unpleasant to look at. The first idea was to just make the green overlay be rendered around light sources, to reward players who put lights into their bases, by not making the base look worse with nightvision on. This didn’t look too good, and as we were trying to figure out how to improve it, other developers, especially artists, caught on to what we were doing, and started to provide their own ideas. Next we tried to darken only the red and blue channels when nightvision is on. This will make the picture green without losing contrast and we can drop the green overlay. We kept “not applying effect onto lighted area” logic and it started to look interesting. Albert wasn’t happy with the result though, so we continued experimenting. We added a soft green tint to lighted areas, and a bright green glow onto the transition between light and darkness. Then we added white highlights to light sources and it finally started to pleasant to look at. We will stick with this version for time being, but plan to work on it more. We can’t agree if this change is for better or worse even inside the team. It seems everybody has their own idea about how nightvision effect should look like and what benefits it should provide to players. For example it would be nice to have goggles with greyscale effect that would highlight biters. So maybe heat vision?
